HyperText Transfer Protocol (HTTP) was designed for browsing networks—such as the Internet—and not for delivery of streaming media. However, widespread support for HTTP in firewalls and proxy servers, has triggered the development of various ways for delivering streaming media using HTTP. By using HTTP, the streaming media data can traverse firewalls that might be blocking other streaming media networking protocols.
Typically, a media player will establish an HTTP connection to a media server through a firewall or proxy server. The server's response to the HTTP request contains the streaming media data. The streaming media data always flows to the entity that made the initial HTTP request, i.e., the client.
Sometimes it is desirable to stream content from a client to a server. This is the case when multimedia data is assembled at a client and uploaded to a server for access at the server or for distribution to other servers and/or clients. The problem is that HTTP only supports streaming from a server to a client, and not vice-versa.
A typical approach to dealing with this problem is to reverse the roles of client and server and have a server initiate a streaming session with a client. In such a scenario, the server acts as a media player and the client acts as a media server. The multimedia content may then stream from the client to the server.
A problem with this technique occurs when such client to server streaming is attempted over connections that utilize a firewalls or a proxy server. Such devices usually block incoming connections from reaching the server.
Another problem with attempts to stream content from a client to a server is that HTTP requires that the size of data that is sent must be specified in advance. However, an encoder does not usually know the size of the data in advance and cannot provide this information.